home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
EnigmA Amiga Run 1998 May
/
EnigmA AMIGA RUN 27 (1998)(G.R. Edizioni)(IT)[!][issue 1998-05].iso
/
earcd
/
sinclair-ql
/
c68patch_readme
< prev
next >
Wrap
Text File
|
1998-02-24
|
4KB
|
155 lines
Short: patch C68 programs to be COPYBACK friendly
Author: Mark J Swift
Version: 1.01
Uploader: msw@blackpool.ac.uk
This BASIC program patches C68 and C68 compiled programs to work
with 68040 and 68060 processors with COPYBACK enabled.
ARCHIVE CONTENTS
C68PATCH_bas - The patcher program.
C68PATCH_readme - This file.
COMPATIBILITY
Works on current versions of C68 that I have tried.
WHY IS IT NECESSARY?
On machines with 68040 and 68060 processors, enabling the COPYBACK cache
can give substantial speed increases since memory is only updated from
the caches when absolutely necessary. Thus with COPYBACK enabled, it is
ESSENTIAL to flush the caches out to memory before they are cleared or
disabled.
The C68 cache routines are inadequate in this respect.
From a disassembly It can be seen that before the compiler relocates
itself, the caches are disabled by the following subroutine:
CACHOFF:
cmpi.b #$20,$A1(a6)
bls.s CACHOFX
*
movec cacr,d0
* 1=data cache enable (>=040)
* | 1=instr cache enable (>=040)
* | | 1=clear data cache (030)
* | | | 1=data cache enable (030)
* | | | | 1=clear instr cache (020,030)
* | | | | | 1=instr cache enable(020,030)
* | | | | | |
move.l #%00000000000000000000100000001000,d1
movec d1,cacr
*
CACHOFX:
rts
On 030 processors this clears (bits 3 and 11 set) the data and
instruction caches and also disables them (bits 0 and 8 clear).
On the >=040 processors the code simply disables the caches. It
does not update the memory from the caches.
In most cases on the '040 the code will be sufficient (i.e it usually
works). However on an '040 with COPYBACK enabled the subroutine always
fails - usually with a corrupted return stack.
Here is what happens...
The subroutine CACHEOFF is called and the return address is pushed on
the stack. However with COPYBACK enabled the return address is written
to the data cache but not written through to memory. Next, the subroutine
disables the caches but does not flush them to memory beforehand. Now
memory does not contain up-to-date information and cache contents are
already lost. This means that the return stack will NOT contain the
correct return address - so the RTS instruction bombs the machine.
There is also a section of code that sets the cache to a value passed
in d0. This also fails to flush the caches:
SETCACH:
tst.l d0
beq.s SETCACHX
cmpi.b #$40,$A1(a6)
blt.s SETCACH2030
cinva ic/dc
SETCACH2030:
movec d0,cacr
SETCACHX:
rts
C68 can be fixed by replacing the above routines as follows:
*******************************************************************
*
* routine to disable the instruction & data caches
* Exit: d0 = previous CACR value
*
CACHOFF:
moveq #0,d0
*******************************************************************
*
* routine to set the CACR
* Entry: d0 = value to write to CACR
* Exit: d0 = previous CACR value
*
SETCACH:
move.l d1,-(a7)
cmpi.b #$10,$A1(a6)
bls.s SETCACHX exit if 010 or less
movec cacr,d1
exg d1,d0 old cacr value => d0
ori.w #$0808,d1 on 020/030 always clear caches
cmpi.b #$30,$A1(a6)
bls.s SETCACHSET
tst.w d0 check 040 bits
bpl.s SETCACHDCHK branch if instruction cache off
cpusha ic otherwise update memory from cache
SETCACHDCHK:
tst.l d0 check 040 bits
bpl.s SETCACHDINV branch if data cache off
cpusha dc otherwise update memory from cache
tst.l d1 check 040 bits
bmi.s SETCACHIINV branch if leaving data cache on
SETCACHDINV:
cinva dc invalidate cache
SETCACHIINV:
cinva ic invalidate cache
SETCACHSET:
movec d1,cacr set the cache
SETCACHX:
move.l (a7)+,d1
rts
*******************************************************************
CONTACT
post: MARK J SWIFT e-mail: msw@blackpool.ac.uk
175 CHURCH STREET
BLACKPOOL
LANCS
FY1 3NX